Technology for real-time detection and mitigation of remote vehicle anomalous behavior

ABSTRACT

Systems and methods for real-time detection and mitigation anomalous behavior of a remote vehicle are provided, e.g., vehicle behavior that is consistent with distracted or unexpectedly disabled driving. On-board and off-board sensors associated with a subject vehicle may monitor the subject vehicle&#39;s environment, and behavior characteristics of a remote vehicle operating within the subject vehicle&#39;s environment may be determined based upon collected sensor data. The remote vehicle&#39;s behavior characteristics may be utilized to detect or determine the presence of anomalous behavior, which may be anomalous for the current contextual conditions of the vehicles&#39; environment. Mitigating actions for detected remote vehicle anomalous behaviors may be suggested and/or automatically implemented at the subject vehicle and/or at proximate vehicles to avoid or reduce the risk of accidents, injury, or death resulting from the anomalous behavior. In some situations, authorities may be notified.

CROSS-REFERENCE TO RELATED APPLICATIONS

The present application is a continuation of U.S. patent applicationSer. No. 17/548,126, filed Dec. 10, 2021, entitled “TECHNOLOGY FORREAL-TIME DETECTION AND MITIGATION OF REMOTE VEHICLE ANOMALOUSBEHAVIOR,” which is a continuation of U.S. patent application Ser. No.16/914,032, filed Jun. 26, 2020, entitled “TECHNOLOGY FOR REAL-TIMEDETECTION AND MITIGATION OF REMOTE VEHICLE ANOMALOUS BEHAVIOR,” which isa continuation of U.S. patent application Ser. No. 16/707,912, filedDec. 9, 2019, entitled “TECHNOLOGY FOR REAL-TIME DETECTION ANDMITIGATION OF REMOTE VEHICLE ANOMALOUS BEHAVIOR,” which is acontinuation of U.S. patent application Ser. No. 15/794,252, filed Oct.26, 2017, entitled “TECHNOLOGY FOR REAL-TIME DETECTION AND MITIGATION OFREMOTE VEHICLE ANOMALOUS BEHAVIOR,” the disclosures of each of which areherein incorporated by reference in their entirety.

FIELD OF DISCLOSURE

The present disclosure is directed to the real-time detection andmitigation of anomalous behavior of a remote vehicle. More particularly,the present disclosure is directed to systems, methods, and techniquesfor detecting or determining that a remote vehicle is behavinganomalously based upon sensed data and, in some embodiments, determininga mitigating course of action for other vehicles in the vicinity of theremote vehicle to decrease the risk of accident, injury, or death due tothe remote vehicle's anomalous behavior.

BACKGROUND

Generally, vehicle operators may drive erratically at times. Forexample, some vehicle operators may get distracted (e.g., texting on amobile phone, retrieving a dropped object, etc.), be impaired (e.g.,falling asleep at the wheel, intoxicated, under the influence ofprescription medications, etc.), or in some extreme cases be disabled bya medical emergency (e.g., a heart attack or stroke) while driving. Inanother example, anomalous behavior of a vehicle may be caused by itsdriver responding to an unexpected event (e.g., a deer crossing theroad, road kill, a group of bicyclers and/or pedestrians, an icy patch,potholes, etc.), which drivers of other vehicles may not be able to seeyet. Operating a vehicle while distracted, while unexpectedly disabled,and/or while responding to an unexpected event may lead to erratic,anomalous behavior of the vehicle, which may put the vehicle operator,additional vehicle occupants, and the occupants of other vehicles inclose proximity at risk of an accident, injury, or death. Generallyspeaking, “anomalous” behavior of a vehicle generally refers to vehiclebehavior that deviates from or is inconsistent with common or expectedvehicle behavior (for example, incongruous, inconsistent, abnormal,unusual, erratic, and/or unsafe behavior), and anomalous vehiclebehavior may include vehicle behaviors that increase the risk ofaccident, injury, or death to proximate vehicles and pedestrians.

SUMMARY

The present disclosure generally relates to systems, methods, andtechniques for the detection and mitigation of anomalous behavior of aremote vehicle, e.g., in real-time. Embodiments of example systems andmethods are summarized below. The methods and systems summarized belowmay include additional, less, or alternate actions, including thosediscussed elsewhere herein.

In an embodiment, a method may include monitoring an environment inwhich the first vehicle is operating, e.g., a vehicle environment. Themonitoring of the vehicle environment may use data collected by set ofsensors associated with the first vehicle. The method may also includedetermining, using one or more processors associated with the firstvehicle and based upon a set of sensor data, a set of characteristicsthat is indicative of one or more behaviors of a remote vehicleoperating within the vehicle environment, and accessing, using the oneor more processors, a set of anomalous vehicle behavior characteristicsdetermined based upon a set of historical vehicle behavior data, wherethe set of historical vehicle behavior data is based upon data obtainedby a plurality of sensors while a plurality of drivers operated aplurality of vehicles. The method additionally includes comparing, usingthe one or more processors, the set of characteristics indicative of theone or more behaviors of the remote vehicle with the set of anomalousvehicle behavior characteristics; determining, using the one or moreprocessors and based upon the comparing, that the remote vehicle isexhibiting an anomalous behavior; and mitigating an effect of theanomalous behavior of the remote vehicle, including providing anindication of the detected, anomalous behavior of the remote vehicle tothe first vehicle, a second vehicle operating in the vehicleenvironment, and/or a public safety authority.

In an embodiment, a system for the detection and mitigation of anomalousbehavior of a vehicle is provided. The system may include one or morecommunication interfaces; one or more processors associated with a firstvehicle and communicatively connected to a set of sensors associatedwith the first vehicle via the one or more communication interfaces; oneor more tangible, non-transitory, computer-readable media coupled to theone or more processors; and computer-executable instructions stored onthe one or more computer-readable media thereby particularly configuringthe one or more computer-readable media. The one or more processors maybe configured to execute computer-executable instructions to cause thesystem to monitor, via the set of sensors, an environment in which thefirst vehicle is operating, the environment in which the first vehicleis operating being a vehicle environment; determine, based upon a set ofsensor data generated by the set of sensors, a set of characteristicsindicative of one or more behaviors of a remote vehicle operating withinthe vehicle environment; and access a set of anomalous vehicle behaviorcharacteristics, where the set of anomalous vehicle behaviorcharacteristics is generated from a set of historical vehicle behaviordata, and the set of historical vehicle behavior data corresponds todata obtained by a plurality of sensors while a plurality of driversoperated a plurality of vehicles. The computer-executable instructions,when executed, may further cause the system to compare the set ofcharacteristics indicative of the one or more behaviors of the remotevehicle with the set of anomalous vehicle behavior characteristics;determine, based upon the comparison of the one or more behaviors of theremote vehicle and the set of anomalous vehicle behaviorcharacteristics, an anomalous behavior exhibited by the vehicle; andmitigate an effect of the anomalous behavior of the remote vehicle,which may include providing, via the one or more communicationinterfaces, an indication of the detected, anomalous behavior to thefirst vehicle, a second vehicle operating in the vehicle environment,and/or a public safety authority.

Systems or computer-readable media storing executable instructions forimplementing all or part of the systems and/or methods described hereinmay also be provided in some embodiments. Systems for implementing suchmethods may include one or more of the following: a special-purposecomputing device, a mobile computing device, a personal electronicdevice, an on-board computer or electronic device, one or more remoteservers or cloud computing system, one or more remote data storageentities, one or more sensors, one or more communication modulesconfigured to communicate wirelessly via radio links, radio frequencylinks, and/or wireless communication channels, and/or one or morenon-transitory, tangible program memories coupled to one or moreprocessors of the special-purpose computing device, mobile computingdevice, personal electronic device, on-board computer or electronicdevice, and/or one or more remote servers or cloud computing system.Such program memories may store instructions, which, when executed bythe one or more processors, may cause a system described herein toimplement part or all of one or more methods described herein.Additional or alternative features described herein below may beincluded in some embodiments.

BRIEF DESCRIPTION OF THE FIGURES

Advantages will become more apparent to those skilled in the art fromthe following description of the preferred embodiments which have beenshown and described by way of illustration. As will be realized, thepresent embodiments may be capable of other and different embodiments,and their details are capable of modification in various respects.Accordingly, the drawings and description are to be regarded asillustrative in nature and not as restrictive.

The figures described below depict various aspects of the applications,methods, and systems disclosed herein. It should be understood that eachfigure depicts an embodiment of a particular aspect of the disclosedapplications, systems and methods, and that each of the figures isintended to accord with a possible embodiment thereof. Furthermore,wherever possible, the following description refers to the referencenumerals included in the following figures, in which features depictedin multiple figures are designated with consistent reference numerals.

FIGS. 1A and 1B depict exemplary environments within a vehicle thatincludes various components configured to facilitate variousfunctionalities related to real-time detection and mitigation of remotevehicle anomalous behavior, in accordance with some embodiments.

FIG. 2A depicts an exemplary side view of the vehicle of FIGS. 1A and1B, in accordance with some embodiments.

FIG. 2B depicts an exemplary top view of the vehicle of FIGS. 1A and 1B,in accordance with some embodiments.

FIG. 3 depicts an exemplary vehicle environment surrounding a subjectvehicle in which real-time detection and mitigation of remote vehicleanomalous behavior may be implemented, in accordance with someembodiments.

FIG. 4 depicts an exemplary block diagram of a wireless communicationsystem interconnecting a subject vehicle and various components whichmay be utilized for real-time detection and mitigation of remote vehicleanomalous behavior, in accordance with some embodiments.

FIG. 5 depicts a flow diagram of an example method for detecting andmitigating remote vehicle anomalous behavior in real-time, in accordancewith some embodiments.

FIGS. 6A and 6B each depict a respective exemplary display forpresentation on user interfaces and associated with displaying detectedremote vehicle anomalous behavior and mitigation information, inaccordance with some embodiments.

FIG. 7 provides a block diagram of an exemplary remote server which maybe utilized in conjunction with embodiments of the systems, methods, andtechniques for real-time detection and mitigation of remote vehicleanomalous behavior disclosed herein, in accordance with someembodiments.

FIG. 8 provides a block diagram of an exemplary electronic device whichmay be utilized in conjunction with embodiments of the systems, methods,and techniques for real-time detection and mitigation of remote vehicleanomalous behavior disclosed herein, in accordance with someembodiments.

DETAILED DESCRIPTION

The present embodiments may relate to, inter alia, novel real-timedetection and mitigation of anomalous behavior of a remote vehicle. Asgenerally used herein, the term “remote” vehicle generally refers toanother vehicle operating in the environment of a subject vehicle beingoperated by a driver. That is, the term “remote” is with respect to thesubject vehicle. Additionally, as used herein, the terms “vehicle” and“automobile” are used interchangeably, and generally refer to any typeof powered transportation device, which includes, and is not limited to,a car, truck, bus, motorcycle, or boat, and may include fully- orpartially-automated, self-driving, or autonomous vehicles.

As previously discussed, some vehicle operators may get distracted,become impaired, or unexpectedly disabled while operating a vehicle.Vehicle operators who are distracted, impaired, or unexpectedly disabledmay operate the vehicle erratically, and thus the vehicle may exhibitanomalous behavior. For example, when a vehicle operator is sleepy, thevehicle that he or she is operating may swerve erratically. In anotherexample, a vehicle may intermittently speed up and slow down while avehicle operator is texting. Other examples of anomalous vehiclebehaviors are possible. Generally speaking, anomalous vehicle behaviors,as generally referred to herein, refers to operational behaviors of avehicle that are visibly, or observably out of the ordinary,incongruous, inconsistent, abnormal, unusual, erratic, unsafe, and/orunexpected (e.g., for given contextual or environmental conditions), andwhich may be indicative of the driver being distracted or suddenlydisabled, such as the driver suffering an unexpected medical impairment,being intoxicated or otherwise chemically affected, falling asleep,searching for something under the seat, texting, interacting with his orher smartphone or device, etc.

Conventionally, it falls upon each driver who is operating a vehicle inthe vicinity of the anomalously-behaving vehicle to individually noticethe anomalous behavior of the remote vehicle and to responsively adjusthis or her driving behavior to reduce the risk of accident, injury,and/or death. For example, a driver who notices the anomalous behaviorof a remote vehicle may slow down and create more distance betweenhis/her vehicle and the remote vehicle. Alternatively, the noticingdriver may speed up and pass (while giving wide berth to) theanomalously-behaving vehicle. However, as each individual operates hisor her vehicle independently without knowledge of what other vehicleoperators in the vicinity are (or are not) noticing and planning to do,the mitigating actions that each individual driver chooses to take maycontradict other drivers' actions. Accordingly, the individual actionsof multiple drivers may collectively cause an even more risky drivingenvironment. Further, different individuals may notice and/or interpretanomalous behavior of a remote vehicle differently and at differenttimes (if at all). For example, an individual may only become aware ofanomalous behavior of a remote vehicle only when his/her vehicle is veryclose to the other vehicle. At that point, it may be too late to take amitigating action such as changing lanes or changing the route of theirvehicle, and the individual may face an unavoidable dangerous situation,especially if other vehicles are in close vicinity.

The novel systems, methods, and/or techniques disclosed herein, though,may address these and other dangerous driving situations byautomatically detecting, identifying, or determining a remote vehicle'sanomalous behavior and, in some embodiments, automatically suggesting oreven automatically causing mitigating actions to be performed orimplemented by one or more vehicles operating in the vicinity of theremote vehicle, thereby reducing risk of accident, injury, or death, andincreasing the safety of the driving environment. For example, the novelsystems, methods, and/or techniques disclosed herein may leverageinformation acquired by various on-board and off-board sensors toautomatically detect and/or identify anomalous behavior of a remotevehicle. Additionally, the systems, methods, and/or techniques disclosedherein may alert a vehicle driver or operator of a subject vehicle ofthe detected or identified anomalous behavior of a remote vehicle, e.g.,through the use of an electronic device associated with the subjectvehicle. Further, in some embodiments, the systems, methods, and/ortechniques disclosed herein may suggest or provide, to one or moredrivers of vehicles in the vicinity of or proximate to theanomalously-behaving remote vehicle, respective mitigating actions forone or more drivers to perform in order to create a safer drivingenvironment for the subject vehicle, its operator/driver, and/orproximate vehicles and pedestrians. In some embodiments, the novelsystems, methods, and/or techniques disclosed herein may send commandsor instructions to one or more surrounding vehicles to automatically orautonomously perform or implement a mitigating action in response to thedetected anomalous behavior of the remote vehicle. Further, in somecases, the novel systems, methods, and/or techniques disclosed hereinmay automatically notify a public authority of the detected, anomalousbehavior of the remote vehicle.

The novel systems, methods, and techniques described herein offernumerous benefits. For example, the detection or identification of aremote vehicle exhibiting anomalous behavior may be more quickly andaccurately identified or determined as compared to relying on anindividual driver to notice and correctly identify the anomalousbehavior. Additionally or alternatively, more than one vehicle and/orrespective driver in the vicinity of an anomalously-behaving remotevehicle may be notified of the remote vehicle's detected anomalousbehavior. As such, collective mitigation actions taken by multipledrivers may be coordinated across multiple vehicles and, in thescenarios in which vehicle behavior is able to be automaticallymodified, may be performed more quickly, thereby increasing the safetyfor all vehicles, drivers, and pedestrians in the vicinity of theanomalously-behaving remote vehicle. Still additionally oralternatively, in some scenarios, a public authority may be notified ofanomalous behavior of a remote vehicle, and emergency response vehiclesmay be deployed before the anomalous behavior of the remote vehiclecauses an accident, injury, or death. It should be appreciated thatother benefits are envisioned.

Additionally, because the novel systems, methods, and techniquesdisclosed herein employ the automatic detection, collection, compiling,storing, and displaying of data associated with a remote vehicle'sanomalous behavior and, in some embodiments, automatically performing orimplementing mitigating actions, the novel systems, methods, andtechniques are necessarily rooted in computer technology in order toovercome the noted shortcomings that specifically arise in the realm ofdetection and mitigation of anomalous behavior of a remote vehicle,e.g., accuracy of identification of the anomalous behavior, speed ofdetection, speed and appropriateness of mitigating actions, coordinationof multiple mitigating actions, etc. For example, the collection of datafrom sensors that are on-board and/or off-board a driver's vehicle mayprovide various perspectives of a remote vehicle's driving behavior,which allows for the quicker and more accurate detection andidentification of anomalous behavior, especially when compared tocurrently known techniques which rely on the individual ability andjudgment of each driver in the vicinity of the remote vehicle.

Similarly, the novel systems, methods, and/or techniques provideimprovements in technical fields, namely, sensor data processing andgenerating mitigation actions for a vehicle. The various systems,methods, and/or techniques described herein employ complex steps that gobeyond the mere concept of simply retrieving and combining data using acomputer. In particular, the hardware and software components capturesensor data, analyze the sensor data, determine relative location andmovement of multiple vehicles, and determine, generate, and communicatemitigation actions so as to increase the safety of the drivingenvironment. This combination of elements further imposes meaningfullimits in that the operations are applied to improving sensor dataprocessing and generating mitigation actions to improve traffic safetyand lessen the chances of an accident, injury, or death in a meaningfuland effective way.

According to implementations, the novel systems, methods, and/ortechniques disclosed herein may support dynamic, real-time, or nearreal-time analysis of any captured, received, and/or detected data. Inparticular, the systems, methods, and/or techniques disclosed herein mayreceive, in real-time or near real-time, data indicative of anomalousbehavior of a remote vehicle while the driver is operating a subjectvehicle, and may generate corresponding mitigation actions in real-timeand near-real-time so that the behavior of the subject vehicle (and, insome cases, of proximate vehicles) may be adjusted in response tothereby prevent or reduce the occurrence and/or severity of a collision,create a safer vehicle environment, etc.

FIG. 1A illustrates an example depiction of an interior of a vehicle 100(e.g., a “subject” vehicle) that may include various componentsassociated with and/or utilized by embodiments of the systems, methods,and techniques disclosed herein for detecting and mitigating, inreal-time, the anomalous behavior of remote vehicles that are operatingin the environment or vicinity of the subject vehicle 100. In somescenarios, a person or individual 105 may be transported by the vehicle100. In FIG. 1A, the individual 105 being transported by the vehicle 100is depicted as a driver sitting in the driver's seat of the vehicle 100and operating the vehicle 100. However, it should be appreciated thatthe individual 105 may be a passenger of the vehicle, and may sit in afront passenger seat or any of a set of rear passenger seats. Inscenarios in which the individual 105 is a passenger of the vehicle 100,another individual may operate the vehicle 100, and/or the vehicle 100may operate in a fully- or partially-autonomous manner.

The vehicle 100 may be configured with an electronic device 110configured with any combination of software and hardware components. Insome implementations, the electronic device 110 may be included as partof an on-board diagnostic (OBD) system or any other type of systemconfigured to be installed in the vehicle 100, such as an originalequipment manufacturer (OEM) system or an after-market system. As such,the electronic device 110 is generally referred to herein as a “vehicle”electronic device 110. In some implementations, the vehicle electronicdevice 110 may be configured to interface with additional components(e.g., vehicle sensors and/or various vehicle behavior and/oroperational control systems) of the vehicle 100. In FIG. 1A, only onevehicle electronic device 110 is depicted, although it is understood inother embodiments, multiple vehicle electronic devices 110 may beinstalled in the vehicle 100 and may be communicatively connected. Forease of reading, though, the vehicle electronic device 110 is referredto herein using the singular tense.

FIG. 1B depicts another configuration of an interior of the vehicle 100that may include various components associated with the systems andmethods associated with and/or utilized by embodiments of the systems,methods, and techniques disclosed herein for real-time detection andmitigation of remote vehicle anomalous behavior. Similar to thedepiction of FIG. 1A, the depiction of FIG. 1B illustrates theindividual 105 who may be an operator or passenger of the vehicle. Theindividual 105 may access and interface with an electronic device 115that may be located within the vehicle 100. Although FIG. 1B depicts theindividual 105 holding the electronic device 115, it should beappreciated that the electronic device 115 may be located within thevehicle 100 without the individual 105 physically contacting theelectronic device 115. For example, the electronic device 115 may besecured within a mount.

According to embodiments, the electronic device 115 may be any type ofelectronic device such as a mobile device (e.g., a smartphone), whichmay be releasably and fixedly secured to the vehicle 100. It should beappreciated that other types of portable electronic devices and/ormobile devices are envisioned, such as notebook computers, tablets,phablets, GPS (Global Positioning System) or GPS-enabled devices, smartwatches, smart glasses, smart bracelets, wearable electronics, PDAs(personal digital assistants), pagers, computing devices configured forwireless communication, and/or the like. Accordingly, the electronicdevice 115 is generally referred to herein as a “portable” electronicdevice 115. In some implementations, the portable electronic device 115may be configured to interface with additional components (e.g., in awired and/or wireless manner) of the vehicle 100, such as vehiclesensors and/or the vehicle electronic device 110.

It is noted that, in various embodiments, a vehicle 100 may include thevehicle electronic device 110 and not the portable electronic device115, a vehicle 100 may include the portable electronic device 115 andnot the vehicle electronic device 110, or a vehicle 100 may include boththe vehicle electronic device 110 and the portable electronic device115. In some embodiments, the vehicle electronic device 100 and theportable electronic device 115 may be communicatively connected, e.g.,via a wired or wireless link.

FIG. 2A illustrates an exemplary depiction 200 of a side view of avehicle 210 positioned on a roadway 240 with an exemplary view of thelocations of example components of a system for real-time detection andmitigation of anomalous behavior of other vehicles that are remote withrespect to the vehicle 210. In an embodiment, the vehicle 210 may be animplementation of the vehicle 100 of FIG. 1A and/or FIG. 1B. In theimplementation illustrated in FIG. 2A, an electronic device 230 isdepicted as being located in the vicinity of the center console of thevehicle 210. In other implementations, the electronic device 230 may belocated in other parts of the vehicle 210. The electronic device 230 maycomprise, for example, the vehicle electronic device 110 of FIG. 1Aand/or the portable electronic device 115 of FIG. 1B.

Additionally, in FIG. 2A, a set of sensors 220 a-220 d (collectivelyreferred to as sensors 220) are disposed at different locations on or atthe vehicle 210. Generally speaking, the sensors 220 a-220 d may senseconditions of and/or detect objects disposed in the environment (and anymovement or behavior thereof) in which the vehicle 210 is operating, andmay collect data that is indicative and/or descriptive of the sensedconditions and/or objects. In some configurations, the sensors 220 a-220d may be disposed on or near the exterior of the vehicle 210, however,in some configurations, one or more of the sensors 220 a-220 d may bedisposed on or in the interior of the vehicle 210 and facing theexterior environment in which the vehicle 210 is disposed (e.g.,outwardly facing). In some configurations, at least one of the sensors220 a-220 d may be included on or integral to the electronic device 230.For example, at least one of the sensors 220 a-220 d may be included onor integral to a portable electronic device 115 being transported by thevehicle 210. Whether disposed at or on the vehicle 210 or disposed at oron a portable device 115 being transported by the vehicle 210, though,the sensors 220 a-220 d are generally referred to herein as “on-boardsensors 220,” as the sensors 220 are being transported by the vehicle210. In various implementations, more or fewer numbers of on-boardsensors 220 may be disposed at the vehicle 210, and/or the on-boardsensors 220 may be disposed at locations at the vehicle 210 differentthan those which are depicted in FIG. 2A.

The sensors 220 a-220 d may comprise sensors that utilize any suitabledetection or sensing technology, such as radar sensors, LIDAR sensors,ultrasonic sensors, infrared sensors, sensors that utilize some othertype of electromagnetic energy, location tracking sensors, proximitysensors, and the like. The sensors 220 a-220 d may include sensors ofmultiple different sensing/detection technologies, in some embodiments.Generally speaking, the on-board sensors 220 a-220 d may actively orpassively scan the environment external to the vehicle 210 for objects(e.g., other vehicles, buildings, pedestrians, trees, gates, barriers,animals, etc.) and their movement, weather conditions (e.g.,precipitation, wind, visibility, or temperature), roadway topographies,road conditions (e.g., lane markings, potholes, road material, traction,or slope), traffic conditions (e.g., traffic density, trafficcongestion, etc.), signs or signals (e.g., traffic signals, speedlimits, other jurisdictional signage, construction signs, building signsor numbers, or control gates), infrastructure components (e.g., bridges,tunnels, construction barriers, street lights, etc.), and/or otherinformation that is indicative and/or descriptive of the environment inwhich the vehicle 210 is operating. Information or data that isgenerated or received by the on-board sensors 220 a-220 d may becommunicated to the electronic device 230, for example.

FIG. 2B illustrates an exemplary depiction 250 of a top view of thevehicle 210 of FIG. 2A positioned on a roadway 240 with an exemplaryview of the locations of example components of the system for real-timedetection and mitigation of anomalous behavior of remote vehicles withrespect to the vehicle 210. FIG. 2B depicts the electronic device 230and sensors 220 a-220 d of FIG. 2A, and depicts additional on-boardsensors 220 e-220 f. Similar to the on-board sensors 220 a-220 d,on-board sensors 220 e-220 f may be any type or types of sensing and/ordetecting sensors, and are illustrated as being disposed at differentlocations on the exterior of the vehicle 210. In other implementations,there may be more or fewer on-board sensors 220 a-220 f and the sensors220 a-220 f may be disposed at different locations (e.g., at differentexterior and/or interior locations that position respective sensors tobe outwardly facing) at the vehicle 210 than that which is depicted inFIG. 2B. In some embodiments, at least one of the sensors 220 a-220 fmay be included on or integral to the electronic device 230. Forexample, at least one of the sensors 220 a-220 f may be included on orintegral to a portable electronic device 115. At any rate, informationor data that is generated or received by the on-board sensors 220 a-220f may be communicated to the electronic device 230, for example.

FIG. 3 illustrates an exemplary vehicle environment 300 depicting a setof vehicles in operation on a roadway 305. In particular, theenvironment 300 may include a first vehicle 310 including a respectiveelectronic device (ED1) 312 and one or more on-board sensors 314 a-314 b(collectively referred to as the on-board sensors 314) disposed at thefirst vehicle 310. The environment 300 may also include a second vehicle320 including a respective electronic device (ED2) 322 and one or moreon-board sensors 324 a-324 b (collectively referred to as on-boardsensors 324) disposed at the second vehicle 320, and a third vehicle 330including a respective electronic device (ED3) 332 and one or moreon-board sensors 334 a-334 b (collectively referred to as on-boardsensors 334) disposed at the third vehicle 330. In an embodiment, theelectronic devices (ED1, ED2, and ED3) 310, 320, and 330 may berespective instances of the vehicle electronic device 110 and/or theportable electronic device 115, or the electronic device 230 of FIGS. 2Aand 2B, and the on-board sensors 314, 324, and 334 may be respectiveinstances of the on-board sensors 220 of FIGS. 2A and 2B. It isunderstood, however, that more or fewer on-board sensors 314, 324, and334 may be respectively disposed at the vehicles 310, 320, 330, and saidon-board sensors 314, 324, and 334 may be located at different locationsat or on their respective vehicles than what is depicted in FIG. 3 .

As also illustrated in FIG. 3 , the environment 300 includes a remotevehicle 340 operating on the roadway 305 in the vicinity of the first,second, and third vehicles 310, 320, and 330. FIG. 3 illustrates theremote vehicle 340, the first vehicle 310, and the second vehicle 320 astraveling in the same direction on the roadway 305, while the thirdvehicle 330 is traveling in the opposite direction as the vehicles 310,320, 340. FIG. 3 further depicts one or more street lights 350 a-350 b(collectively referred to as street lights 350) disposed along theroadway 305. Each of the street lights 350 may include at least onerespective sensor 354 a and 354 b (collectively referred to as sensors354) disposed thereon. It is understood that, in some embodiments, atleast one of the each street lights 350 may respectively include morethan one sensor 354, and/or the sensor or sensors 354 may be located atdifferent locations on their respective street light 354 than what isdepicted in FIG. 3 . Further, while FIG. 3 illustrates the sensors 354being disposed on street lights 350, in some scenarios, one or more ofthe sensors 354 may be additionally or alternatively disposed on othercomponents or fixtures that are disposed or located within theenvironment 300 in which the vehicles 310, 320, 330, and 340 areoperating (not shown). For example, one or more sensors 354 may bedisposed on infrastructure components such as roadways, bridges, trafficsignals, gates, switches, crossings, overhead passes, tunnels, parkinglots or garages, toll booths, docks, hangars, or other similar physicalportions of a transportation system's infrastructure. Additionally oralternatively, one or more sensors 354 may be disposed on fixtures suchas traffic street signs, railings, posts, guardrails, billboards,portable emergency signage, etc. In some implementations, at least someof the sensors 354 may be included in a sensor network, such as anInternet-of-Things (IoT) sensor network deployed in a city or by someother jurisdiction, a sensor network that supports autonomous vehicles,and/or some other type of sensor network. For ease of discussion, thesensors 354 are generally referred to herein as “off-board” sensors 354,as the sensors 354 are disposed off-board (e.g., separately from orexternal to, or not transported by) the vehicles 310, 320, 330. It isnoted, though, that off-board sensors may not necessarily be limited tosensors that are disposed on fixtures or infrastructure components. Insome environments, off-board sensors may be disposed in other vehicles.For example, with respect to the vehicle 310, sensors 324 disposed atvehicle 320 and sensors 334 disposed at vehicle 330 are considered“off-board” the vehicle 310, as the sensors 324, 334 are disposedseparately from and external to the vehicle 310 and as the sensors 324,334 are not being transported by the vehicle 310. Generally speaking,off-board sensors 354 (whether disposed on fixtures, on infrastructurecomponents, or at other vehicles) may sense conditions of and/or objectsdisposed in the environment in which a subject vehicle is operating, andmay collect data indicative and/or descriptive of the sensed conditionsand/or objects.

In the environment 300, the on-board sensors 314 associated with thefirst vehicle 310 may detect 316 a-316 b (collectively referred to as316) the movement and behavior of the remote vehicle 340. The electronicdevice (ED1) 312 associated with the first vehicle 310 may receivecorresponding sensor data from its respective on-board sensors 314 andmay analyze the sensor data and determine that the remote vehicle 340may be exhibiting anomalous behavior. The on-board sensors 324 and 334associated with the second vehicle 320 and third vehicle 330 may alsorespectively detect 326 a-326 b (collectively referred to as 326) and336 a-336 b (collectively referred to as 336) the movement and behaviorof the remote vehicle 340, and may provide respective sensor data totheir respective electronic devices ED2 and ED3. In someimplementations, the electronic device (ED1) 312 may communicate 360 aand 360 b with electronic device (ED2) 322 and/or electronic device(ED3) 332 to obtain sensor data generated by the on-board sensors 324and 334 respectively associated with the second vehicle 320 and thethird vehicle 330. For example, the electronic device ED1 312 mayinitiate requests, for respective sensor data, to electronic devices(ED2 and ED3) 322 and 332, and may receive corresponding responsesincluding the requested sensor data (e.g., references 360 a and 360 b).In some examples, detected sensor data may be automatically transmittedor broadcast by an electronic device (e.g., the electronic device ED2322) to the other electronic devices in the vicinity of or proximate toED2 322 (e.g., to ED1 312 and ED3 332) without first receiving a requestfor the data, e.g., when other electronic devices being transported byother vehicles are communicatively connected, such as in a network ofconnected vehicles (not shown). It should be appreciated that electronicdevice (ED2) 322 and electronic device (ED3) 332 may also communicate360 c with each other.

Additionally, in the environment 300, the off-board sensors 354 maydetect 356 a-356 b the movement and behavior of the remote vehicle 340,and the sensor data generated by the off-board sensors 354 may beobtained by at least some of the electronic devices (ED1, ED2, ED3) 312,322, 332. For example, the off-board sensors 354 may be communicativelyconnected, via one or more communication interfaces, to a remote serveror another computing device (not shown in FIG. 3 ), and the electronicdevice (ED1) 312 may access the sensor data from the off-board sensors354 from the remote server or the another computing device via a networkconnection. In an additional or alternative example, at least some ofthe sensor data generated by the off-board sensors 354 may be obtainedby the electronic device (ED2) 322 via a wireless connection (which maybe a direct wireless connection) without the use of any interveningremote server or computing device. Still additionally or alternatively,at least some of the sensor data generated by the off-board sensors 354may be automatically broadcast and/or transmitted to vehicle electronicdevices (e.g., ED1 312, ED2 322, ED3 332) that are in the vicinity ofthe sensors 354 (e.g., without having to be first requested), such aswhen the off-board sensors 354 are included in a sensor network that iscommunicatively connected to vehicle electronic devices (e.g., ED1 312,ED2 322, ED3 332). For instance, the off-board sensors 354 may beincluded in a sensor network that supports autonomous vehicle operationon the roadway 350. In some embodiments, the electronic devices (ED1,ED2, and ED3) 312, 322, 332 may also transmit sensor data to the remoteserver via a network connection, e.g., for historization or long termstorage.

FIG. 4 illustrates an exemplary block diagram of an interconnectedcommunication system 400 which may be utilized in conjunction with thenovel systems, methods, and/or techniques disclosed herein. Thehigh-level architecture of the system 400 illustrated in FIG. 4 mayinclude both hardware and software applications, as well as various datacommunications channels, at least some of which are wireless datacommunications channels, for communicating data between the varioushardware and software components, as is described below. The system 400may be roughly divided into front-end components 402 and back-endcomponents 404. Generally speaking, the front-end components 402 mayobtain information regarding the behavior of vehicles (e.g., a car,truck, motorcycle, etc.) that are being operated by respective drivers.The front-end components 402 may include, for example, one or moreon-board vehicle electronic devices, e.g., the on-board vehicleelectronic devices 412, 422, 432 that are respectively being transportedby the vehicles 410, 420, 430. The front-end components may also includeone or more on-board sensors (not shown) that are being transported byone or more of the vehicles 410, 420, 430, and/or one or more off-boardsensors 440 disposed in the environment in which the vehicles 410, 420,439 are operating. In an embodiment, the one or more on-board vehicleelectronic devices may include one or more of the electronic devices110, 115, 230, 312, 322, 332; the one or more on-board sensors mayinclude one or more of the on-board sensors 220, 314, 324, 334; and/orone or more off-board sensors 440 may include one or more of theoff-board sensors 354. Generally speaking, in the system 400, any ofelectronic devices 412, 422, 432 may be communicatively connected in awireless manner with any one or more others of the electronic devices412, 422, 432, e.g., via a direct wireless connection, or via a wirelessconnection to one or more networks 450, which may serve as anintermediary router between electronic devices 412, 422, 432. Similarly,any of electronic devices 412, 422, 432 may be communicatively connectedin a wireless manner with one or more off-board sensors 440, e.g., via adirect wireless connection, or via a wireless connection to the one ormore networks 450, which may serve as an intermediary router between theelectronic devices 412, 422, 432 and one or more off-board sensors 440.

The back-end components 404 may be communicatively connected to thefront-end components 402 via the one or more networks 450. The one ormore networks 450 may support any one or more types of datacommunication using one or more wired and/or wireless standards ortechnologies (e.g., GSM, CDMA, TDMA, WCDMA, LTE, EDGE, OFDM, GPRS,EV-DO, UWB, Internet, IEEE 802 including Ethernet, WiMAX, Wi-Fi,Bluetooth, and/or others). The one or more networks 450 may include oneor more private networks, local networks, and/or dedicated frequencybands. In some embodiments, the one or more networks 450 may include oneor more public networks, such as the Internet or cellular data networks,and/or may include one or more private networks.

Additionally, the back-end components 404 may include a remote server460 that may interface with (e.g., read-only, or read-write) one or moredata storage devices 470 (which is also referred to interchangeablyherein as “one or more databases 470”). The one or more databases 470may contain or store various information and data, such as data and/orinformation 475 that is indicative of the historical behavior of aplurality of vehicles while the vehicles were operated over a pluralityof routes and in varying associated contextual conditions (e.g., weatherconditions, road topography, traffic conditions, road conditions, and/orother environmental conditions). At least a portion of the historicalvehicle behavior information 475 may have been obtained by on-boardand/or off-board sensors associated with a plurality of vehicles, forexample, and optionally from or based upon one or more third-party datafeeds (e.g., a weather data feed, an IoT (Internet of Things) sensornetwork implemented in a city, etc.). The one or more data storagedevices 470 may also contain or store other information pertaining tovehicle operations, such as information/data indicative of roadwayswhich may be utilized for navigation directions (not shown), driverperformance scores or indications, etc. The one or more data storagedevices for databases 470 may be implemented by one or more data storageentities, such as by a data bank, cloud data storage, and/or any othersuitable implementation. Similarly, the remote server 460 may beimplemented by one or more computing devices, such as by a bank ofservers, a computing cloud, and/or any other suitable implementation.For ease of discussion (and not for limitation purposes), though, theremote server 460 and the data storage device/database 470 are referredto herein using the singular tense.

FIG. 5 depicts a flow chart of an example method 500 for detecting andmitigating anomalous behavior of a vehicle. At least a portion of themethod 500 may be performed, in an embodiment, by a vehicle electronicdevice, such as the vehicle electronic device 110 and/or the portableelectronic device 115 disposed at the vehicle 100, the electronic device230 disposed at the vehicle 210, the electronic devices 312, 322, 332respectively disposed at the vehicles 310, 320, 330, and/or theelectronic devices 412, 422, 432 respectively disposed at the vehicles410, 420, 430. In some embodiments, at least a portion of the method 500may be performed by a vehicle electronic device and/or a portableelectronic device in conjunction with one or more other vehicle andportable electronic devices disposed in other vehicles operating in thevicinity of the subject vehicle in which the electronic device is beingtransported, and/or in conjunction with a remote computing device orserver, such as the remote server 460. For ease of discussion, and notfor limitation purposes, the method 500 is discussed with simultaneousreference to FIGS. 1-4 , although it is understood that the method 500may operate in conjunction with other systems, vehicles, and/orcomputing devices.

At a block 502, the method 500 may include monitoring an environment inwhich a vehicle, e.g., a subject vehicle, is operating. For example, theenvironment in which the subject vehicle is operating may be theenvironment 300 shown in FIG. 3 , or may be a similar or differentenvironment in which vehicles may operate. The subject vehicle may beoperated by a driver, or the subject vehicle may be fully- orpartially-autonomously operated. The monitoring 502 of the subjectvehicle's environment may include obtaining or collecting data generatedby sensors that are associated with the subject vehicle. Such sensorsmay include one or more on-board sensors of the subject vehicle (e.g.,the on-board sensors 220, 314, 324, or 334), for example. In someembodiments, the sensors associated with the subject vehicle and fromwhich data is obtained or collected may include one or more off-boardsensors associated with the subject vehicle. The one or more off-boardsensors may include sensors that are disposed at other vehicles (e.g.,in FIG. 3 the sensors 314, 334 are “off-board” with respect to thesubject vehicle 320), and/or the one or more off-board sensors mayinclude sensors that are disposed on or at infrastructure components orother non-vehicular objects that are located in the environment of thesubject vehicle (e.g., one or more of the off-board sensors 354, 440).

The sensors that are associated with the subject vehicle (whetheron-board and/or off-board) may detect or sense various conditions and/orobjects in the subject vehicle's environment, as well as detect or sensechanges in the various conditions, behaviors, and/or movements of thevarious objects. For example, the sensors may detect or sense a set ofcurrent environmental conditions, such as the presence and/or degree oftraffic congestion, traffic construction, pedestrians, etc. Additionallyor alternatively, the sensors may detect/sense a set of current weatherconditions, such as the presence and/or degree of precipitation, icyroads, fog, etc., and/or the sensors may detect/sense a set of currentroad conditions, such as potholes, merging lanes, speed limit changes,and the like. Generally speaking, the sensors associated with thesubject vehicle may sense or detect one or more of these and othercontextual conditions, attributes, and/or behaviors which are includedin the environment in which the subject vehicle is operating, and maygenerate data indicative of the sensed or detected conditions, e.g.,“sensor data.”

Importantly, at the block 502, the set of sensors that are associatedwith the subject vehicle may detect or sense the presence and movementof one or more other vehicles that are operating in the subjectvehicle's environment, e.g., one or more remote vehicles that are withina threshold distance of the subject vehicle, and may generate sensordata corresponding thereto and/or indicative thereof. At least one ofthe sensed remote vehicles may be traveling on the same roadway as thesubject vehicle, e.g., in the same direction or in an oppositedirection. At least one of the sensed remote vehicles may be travelingon a different roadway in the vicinity of the roadway on which thesubject vehicle is traveling. In an embodiment, the threshold distancemay be indicative of a distance at which one or more sensors maycollectively sense or detect at a given level of accuracy. The thresholddistance may be determined based upon the sensitivity of the sensorsand/or based upon other factors, such as the performance of the driverof the subject vehicle, the current speed of traffic flow, the currenttraffic density, etc.

At a block 505, the method 500 may include determining a set ofcharacteristics that is indicative of one or more behaviors of aparticular remote vehicle operating within the subject vehicle'senvironment. For clarity of discussion, the particular remote vehicle isreferred to herein as a “target” remote vehicle. In an embodiment,determining 505 the set of characteristics indicative of the one or morebehaviors of the target remote vehicle may include analyzing the sensordata that has been obtained or collected during the monitoring 502. Forexample, determining 505 the set of characteristics of the behavior ofthe target remote vehicle may include filtering the collected sensordata, cleaning the sensor data, and/or evaluating or interpreting atleast some of the collected sensor data (which may be filtered and/orcleaned sensor data) to determine the set of characteristics indicativeof the behavior of the target remote vehicle.

At a block 508, the method 500 may include accessing a set of anomalousvehicle behavior characteristics (an example of which is represented inFIG. 4 by the reference 476). The set of anomalous vehicle behaviorcharacteristics 476 may correspond to a set of anomalous vehiclebehaviors, such as different patterns of vehicle swerving, speeding upand slowing down, frequently changing, driving in two lanes, otherinconsistent or erratic speed patterns, other inconsistent or erraticmovement patterns, etc. Generally speaking, the set of anomalous vehiclebehavior characteristics 476 may provide mappings between variousanomalous vehicle behaviors and respective sets of vehicle behaviorcharacteristics. That is, each anomalous vehicle behavior may beidentified or characterized by a respective set of vehicle behaviorcharacteristics (which may be, for example, a subset of the vehiclebehavior characteristics included in the set of anomalous vehiclebehavior characteristics). For example, a particular set of vehiclebehavior characteristics that occur in combination over time may beindicative of a particular anomalous vehicle behavior.

The set of anomalous vehicle behavior characteristics 476 may begenerated or determined from a set of historical vehicle behavior data,e.g., the set of historical vehicle behavior data 475 of FIG. 4 , thatincludes data indicative of historical vehicle operations and behavior(and, optionally, data indicative of corresponding environmentalconditions and contexts) that have been obtained for multiple vehiclesalong multiple routes and over multiple periods or intervals of time. Inan embodiment, at least a portion of the historical vehicle behaviordata 475 and the set of anomalous behavior characteristics 476 may beremotely stored at and accessed from the data storage device 470, forexample, e.g., by utilizing any suitable local access mechanism (e.g., afunction call, a database read, an API (Application ProgrammingInterface), etc.) and/or any suitable remote access mechanism (e.g., amessage exchange using a communication protocol, a remote API, etc.). Inan embodiment, at least a portion of the historical vehicle behaviordata 475 and the set of anomalous behavior characteristics 476 may belocally stored at and accessed from a data storage device or memory thatis on-board the subject vehicle (not shown), for example, e.g., byutilizing any suitable local access mechanism (e.g., a function call, adatabase read, an API (Application Programming Interface), etc.) and/orany suitable remote access mechanism (e.g., a message exchange using acommunication protocol, a remote API, etc.). At least some of thehistorical vehicle behavior data 475 may have been generated by and/orcollected from multiple sets of on-board and/or off-board sensorsassociated with the multiple vehicles. Typically, but not necessarily,at least a portion of the historical vehicle behavior data 475 may betime-series data.

In an embodiment, at least a portion of the set of anomalous vehiclebehavior characteristics 476 may be determined in real-time based uponhistorical vehicle behavior data 475. Additionally or alternatively, atleast a portion of the set of anomalous vehicle behavior characteristics476 may have been pre-determined, e.g., may have been determined fromthe historical vehicle behavior data 475 a priori. In an exemplary butnon-limiting implementation, the one or more statistical analyses and/orlearning techniques may be applied to the historical vehicle behaviordata 475 to generate or create an anomalous vehicle behavior model 478,which may be, for example, a statistical model. The anomalous vehiclebehavior model 478 may be generated in real-time, e.g., as a part of theblock 508, in an embodiment. In another embodiment, the anomalousvehicle behavior model 478 may have been generated a priori, e.g., priorto the execution of the block 508. At any rate, the anomalous vehiclebehavior model 478 may indicate or define the various weights orweightings of various vehicle behavior characteristics with respect to aparticular anomalous vehicle behavior. As such, the analysis or analysesof the historical vehicle behavior data 475 may define the mappingsbetween the various anomalous vehicle behaviors and the respective setsof vehicle behavior characteristics 476 that are indicative of therespective anomalous vehicle behaviors based upon one or morestatistical analyses/learning techniques that are applied to thehistorical vehicle behavior data 475. Further, in addition todetermining sets of vehicle behavior characteristics 476 that areindicative of anomalous vehicle behaviors, the analysis or analyses ofthe historical vehicle behavior data 475 may determine differentthresholds and/or ranges of the vehicle behavior characteristics (e.g.,over time, magnitudes, etc.) that are indicative of respective anomalousvehicle behaviors. Still further, in some embodiments, multiple models478 may be generated as desired, e.g., for different types of anomalousvehicle behaviors, for determining the absence one or more of one ormore anomalous vehicle behaviors in addition or alternatively todetermining the presence of a particular anomalous vehicle behaviors,etc. At least some of the generated models 478 may be remotely stored atthe data storage device 470 or some other remote memory, and/or at leastsome of the generated models 478 may be locally stored at a data storagedevice or memory that is on-board the subject vehicle (not shown).

At a block 510, the method 500 may include comparing the set of vehiclebehavior characteristics indicative of one or behaviors of the remotevehicle (e.g., as determined at the block 505) with the set of anomalousvehicle behavior characteristics 476 (e.g., as determined or accessed atthe block 508). In an embodiment, comparing 510 the set of vehiclebehavior characteristics of the remote vehicle with a set of anomalousvehicle behavior characteristics 476 may include applying one or moremodels 478 to at least some of the set of vehicle behaviorcharacteristics of the remote vehicle. For example, at least some of theset of vehicle behavior characteristics of the remote vehicle may beinput into one or more models 478, and the one or more models 478 mayoutput an identification or determination of one or more anomalousvehicle behaviors of the remote vehicle based upon the input vehiclebehavior characteristics, where the one or more anomalous vehiclebehaviors have been statistically determined, identified, or learnedbased upon the historical vehicle data 475. In some embodiments, othertechniques for comparing 510 the set of vehicle behavior characteristicsof the remote vehicle with the set of anomalous vehicle behaviorcharacteristics 476 may be utilized, such as determining the presence orabsence of certain vehicle behavior characteristics corresponding to aparticular anomalous vehicle behavior, determining a threshold number ofcertain vehicle behavior characteristics corresponding to the particularanomalous vehicle behavior, and/or other suitable comparison techniques.At any rate, comparing 510 the set of vehicle behavior characteristicsindicative of one or behaviors of the remote vehicle with a set ofanomalous vehicle behavior characteristics 476 may include generating anindication of the respective presence or absence of one or moreanomalous vehicle behaviors. In some embodiments, the comparison 510 maygenerate an indication of the respective identifications of detectedanomalous vehicle behaviors, and optionally, a respective measure ofconfidence or percentage of likelihood for each identification.

At a block 512, the method 500 may include determining or detecting,based upon the comparison 510, whether or not the remote vehicle isexhibiting one or more anomalous behaviors. For example, thedetermination may be based upon an output of the one or more models 478,and/or an output of another comparison technique. Additionally oralternatively, a predetermined threshold corresponding to a measure ofconfidence or percentage of likelihood may be utilized to determine ordetect 512 whether or not the remote vehicle is exhibiting anomalousvehicle behavior. In some embodiments, data indicative of contextualconditions in which the remote vehicle is operating (e.g., weatherconditions, road topography, traffic conditions, road conditions, and/orother environmental conditions) may be utilized to determine or detect512 anomalous vehicle behavior of the remote vehicle. In an embodiment,contextual condition data corresponding to the environment in which theremote vehicle is operating may be obtained by on-board sensors and/oroff-board sensors associated with the subject vehicle. For example, ifthere is a pothole at a certain location in the road, data indicative ofthis particular contextual condition may factor into determining whetheror not the swerving of a remote vehicle is considered anomalous for thegiven contextual condition. It is noted that, in some embodiments, theblocks 510 and 512 may be combined into an integral block. For example,sensed contextual condition data may be input along with the remotevehicle's behavior characteristics into one or more models 478 todetermine whether or not the remote vehicle is exhibiting anomalousbehavior.

If, at the block 512, the method 500 determines that the remote vehicleis not exhibiting anomalous behavior, the method 500 may return to theblock 502 to continue monitoring the environment in which the subjectvehicle is operating. If, at the block 512, the method 500 determinesthat the remote vehicle is exhibiting one or more anomalous behaviors,the method 500 may proceed to block 515.

At the block 515, the method 500 may include mitigating an effect of thedetected anomalous behavior(s) of the remote vehicle. Mitigating 515 theeffect of the remote vehicle's anomalous behavior(s) may includeproviding an indication of the detected, anomalous behavior of theremote vehicle to the subject vehicle. For example, an indication of thedetected, anomalous behavior(s) of the remote vehicle may be provided ata user interface of the subject vehicle, e.g. via the vehicle electronicdevice 110 and/or the portable electronic device 115. Additionally oralternatively, a suggested mitigating action which the driver of thesubject vehicle may choose to take (e.g., slow down, change lanes,re-route, etc.) may be provided at a user interface of the subjectvehicle. In some embodiments, mitigating 515 the effect of the remotevehicle's anomalous behavior(s) may include automatically providing aninstruction to one or more components of the subject vehicle toautomatically modify an operation of the subject vehicle. For example,based upon the detected anomalous behavior(s) of the remote vehicle, thesubject vehicle's speed may be automatically adjusted, the subjectvehicle's brakes may be automatically applied, the subject vehicle maybe re-routed, etc. Such automatic modifications may be applied tofully-or partially-autonomously operated subject vehicles, and/or may beapplied to non-autonomously operated vehicles, as desired.

Mitigating 515 the effects of the remote vehicle's detected anomalousbehavior(s) may include communicating with other vehicles in thevicinity of the subject vehicle (e.g., one or more proximate vehicles),in an embodiment. For example, indications of the detected, anomalousbehavior of the remote vehicle and/or suggested mitigating actions forother drivers to take may be transmitted to one or more proximatevehicles for presentation at their respective user interfaces.Additionally or alternatively, one or more instructions to automaticallymodify respective operations of one or more proximate vehicles may betransmitted to the proximate vehicles. In this manner, mitigatingactions across multiple vehicles in the vicinity of the remote vehiclemay be coordinated so that the chance of an accident or the occurrenceof other undesirable effects of the remote vehicle's anomalous behavioris decreased.

In an embodiment, mitigating 515 the effects of the remote vehicle'sdetected anomalous behavior(s) may include automatically notifying apublic authority of the remote vehicle's anomalous behavior. Forexample, if the identified anomalous behavior of the remote vehicle isconsistent with that of the remote vehicle's driver having a stroke orbeing otherwise impaired, police and/or other medical personnel may beautomatically notified, e.g., by transmitting communications from thesubject vehicle to the appropriate public authorities via the network450.

In some embodiments, the method 500 may include determining oridentifying the one or more mitigating actions of the subject vehicleand/or of the one or more proximate vehicles (not shown). For example,in embodiments in which one or more models 478 are utilized, the one ormore models 478 may output, based upon the remote vehicle's behaviorcharacteristics that are input to the model(s) 478, an indication of oneor more mitigating actions which may be taken to decrease the risk of anaccident or other undesirable event due to the remote vehicle'sanomalous behavior. As such, the one or more mitigating actions may bestatistically determined/identified based upon historical vehicle data475, the identified anomalous behavior of the remote vehicle, and/or thecurrent contextual conditions of the vehicle environment. However, thedetermination of the suggested mitigating actions may be determined oridentified using additional or alternate techniques. For example, thesuggested mitigating actions may be additionally or alternativelydetermined based upon the driver of the subject vehicle (e.g., basedupon the driver's driving performance, the driver's preferences, etc.),the present condition of the subject vehicle, whether or not anyproximate vehicles are communicatively connected to the system 400,and/or other factors.

The method 500 may be performed at least in part by one or moreelectronic devices 110, 115, 230, 312, 322, 332 that are on-board thesubject vehicle. In an embodiment, the entirety of the method 500 may beperformed by the one or more electronic devices 110, 115, 230, 312, 322,332 that are on-board the subject vehicle. In an embodiment, at least aportion of the method 500 is performed by the remote server 460. Forexample, the entirety of the method 500 may be performed by the server460. In some embodiments, the method 500 is performed by the one or moreelectronic devices 110, 115, 230, 312, 322, 332 that are on-board thesubject vehicle in conjunction with the server 460, e.g. via the network450. Generally speaking, at least the steps 505-515 of the method 500may be performed in real-time. That is, mitigating 515 the effect ofanomalous behavior of a remote vehicle that has been detected/determinedfrom sensed behavior of the remote vehicle (e.g., via the blocks 502,505) may be performed or implemented in a short enough time interval sothat any undesirable effects of the detected anomalous vehicle behaviormay be mitigated or prevented.

FIG. 6A illustrates an example display 610 that is associated withreal-time detection and mitigation of remote vehicle anomalous behaviorand that may be presented on a user interface on-board a subjectvehicle, e.g., on a user interface of the electronic device 110, 115,230, 312, 322, and/or 332. The display 610 may include an informationbox 612 that alerts the vehicle operator of a nearby remote vehicle thatis exhibiting anomalous behavior. The display 610 may include a “CLICKHERE FOR SUGGESTED ACTION” selection 614 that enables an accessing toproceed to a subsequent interface that provides a suggested mitigationaction to the accessing user. The display 610 may also include a“CANCEL” selection 616 that enables an accessing user to select todismiss the display 610.

FIG. 6B illustrates another example display 650 that is associated withreal-time detection and mitigation of remote vehicle anomalous behaviorand that may be presented on a user interface on-board a subjectvehicle, e.g., on a user interface of the electronic device 110, 115,230, 312, 322, and/or 332. In some embodiments, the electronic device110, 115, 230, 312, 322, 332 may present the display 650 in response tothe user selecting the “CLICK HERE FOR SUGGESTED ACTION” selection 614of FIG. 6A. The display 650 may include an information box 652 thatidentifies the mitigation action(s) (e.g., alternate navigationdirections to circumvent the anomalous behavior of the remote vehicle,as illustrated in FIG. 6B). Additionally, the display 650 may alsoinclude a “CANCEL” selection 654 that enables an accessing user toselect to dismiss the interface 650.

FIG. 7 illustrates a block diagram 700 of an exemplary server 710 (suchas the remote server 460 as discussed with respect to FIG. 4 ) in whichat least some of the functionalities as discussed herein may beimplemented. It should be noted that, although only a single server 710is shown in FIG. 7 , this is only one of many embodiments. In someembodiments, multiple servers 710 may be configured to have a logicalpresence of a single entity, such as a server bank or an arrangementknown as “cloud computing.” These configurations may provide variousadvantages, such as enabling near real-time uploads and downloads ofinformation as well as periodic uploads and downloads of information.However, for ease of discussion and not for limitation purposes, theserver 710 is referred to herein using the singular tense.

The server 710 may include one or more controllers 720 that areoperatively connected to a data storage device, entity, or database 725(such as the database 470 as discussed with respect to FIG. 4 ) via alink 728, which may include one or more local and/or remote links. Theserver 710 may access data stored in the data storage entity 725 whenexecuting various functions, tasks, and/or techniques associated withthe real-time detection and mitigation of remote vehicle anomalousbehavior. It should be noted that although FIG. 7 depicts a single datastorage entity 725, in embodiments the data storage entities 725 may beimplemented by multiple physical data storage entities, such as a databank or data farm.

The data storage device 725 may be adapted or configured to store datarelated to historical vehicle behavior data obtained by a plurality ofsensors while a plurality of drivers operated a plurality of vehiclesover a plurality of routes during various contextual conditions, e.g.,the historical data 475. Additionally or alternatively, the data storagedevice 725 may store anomalous vehicle behavior models 478, sets ofanomalous vehicle behavior characteristics 476, identities of anomalousvehicle behaviors in the respective mappings to the sets of vehiclebehavior characteristics, and/or other data related to detecting andmitigating anomalous behavior of remote vehicles (not shown). At leastsome of the data stored at the data storage device 725 may be determinedor generated based upon at least a portion of the historical vehiclebehavior data 475, in an embodiment. In embodiments, the data storagedevice 725 may additionally store other types of data related to vehicleoperations, vehicle environments, contextual conditions, driverperformances, etc. Generally, at least some of the data points stored inthe data storage device 725 may be time-stamped and may include anindication of a respective geo-location in which the data point wascollected. That is, at least a portion of the data stored in the datastorage device 725 may include time-series data.

It should be further noted that, while not shown, additional datastorage devices or entities may be linked to the controller(s) 720 in aknown manner, e.g., locally and/or remotely. For example, additionaldatabases and/or data storage devices (not shown) that store varioustypes of information (such as autonomous operation feature information,vehicle accidents, road conditions, vehicle insurance policyinformation, driver performance, or vehicle use information) may belocally and communicatively connected to the controller(s) 720 and/or tothe server 710. Additional databases or data storage devices (not shown)may be remotely communicatively connected to the controller(s) 720and/or to the server 710 via one or more links 730 to one or morenetworks 732, and may store data maintained by third parties (e.g.,weather databases, road construction databases, traffic congestiondatabases, road network databases, IoT (Internet-of-Things) or sensordatabases implemented by a city or other jurisdiction, etc.). In anembodiment, the one or more networks 732 may include the network 450 ofFIG. 4 .

The controller 720 may include one or more program memories 735, one ormore processors 740 (which may be called a microcontroller or amicroprocessor), one or more random-access memories (RAMs) 750, and aninput/output (I/O) circuit 760, all of which may be interconnected viaan address/data bus 755. It should be appreciated that although only onemicroprocessor 740 is shown, the controller 720 may include multiplemicroprocessors 740. Similarly, the memory of the controller 720 mayinclude multiple RAMs 750 and multiple program memories 735, if desired.Although the I/O circuit 760 is shown as a single block in FIG. 7 , itshould be appreciated that the I/O circuit 760 may include a number ofdifferent types of I/O circuits. The RAM 750 and program memories 735may be implemented as semiconductor memories, magnetically readablememories, biologically readable memories, or optically readablememories, for example. The controller 720 may also be operativelyconnected to the network 732 via the link 730.

The controller 720 may further include a number of applications 761-765stored in its program memory 735. In an embodiment, the applications761-765 comprise one or more software applications or sets ofcomputer-executable instructions that are stored on the programmemor(ies) 735 and executable by the processor(s) 740. In an embodiment,at least some of the applications 761-765 may be implemented at leastpartially in firmware and/or in hardware at the server 710. The variousapplications on the server 710 may include, for example, a monitoringapplication 761 for monitoring environments in which vehicles areoperating; an anomalous vehicle behavior characteristics application 762for generating an anomalous vehicle behavior model (e.g., the model 478)based upon a statistical analysis or a learning method performed on aset of historical vehicle behavior data; and an anomalous vehiclebehavior comparison application 763 for comparing a set ofcharacteristics indicative of one or more behaviors of a remote vehiclewith the set of anomalous vehicle behavior characteristics, e.g., byapplying the anomalous vehicle behavior model generated by the anomalousvehicle behavior characteristics application 762 to the set ofcharacteristics indicative of the one or more behavior of the remotevehicle. The program memory 735 may also include any number of otherapplications 763-765. Generally speaking, the applications 761-765 mayperform one or more techniques related to detecting and mitigatinganomalous remote vehicle behavior in real-time. For example, one or moreof the applications 761-765 may perform at least a portion of (and insome cases, the entirety of) any of the methods described herein.

The various applications may be executed on the same computer processor740 or on different computer processors 740 in embodiments, as desired.Further, while the various applications 761-765 are depicted as separateapplications, two or more of the applications 761-765 may be integratedas an integral application, if desired. In some embodiments, at leastone of the applications 761-765 may be implemented in conjunction withanother application (not shown) that is stored and executed at theserver 710, such as a navigation or routing application.

FIG. 8 illustrates a block diagram 800 of an exemplary local electronicdevice 810 (such as one or more of the electronic devices 110, 115, 230,312, 322, 332) in which at least some of the functionalities asdiscussed herein may be implemented. It should be appreciated that thelocal electronic device 810 may be configured to be transported in avehicle and/or to connect to an on-board telematics platform of thevehicle, as discussed herein. Further, it should be appreciated that thelocal electronic device 810 may be integrated into an on-board system ofthe vehicle. In some implementations, the local electronic device 810may operate in conjunction with a remote server (e.g., the remote server460, the server 710) to perform at least some of the functionalitiesdescribed herein.

The local electronic device 810 may include a processor 812 and a memory815. The memory 815 may store an operating system 818 capable offacilitating the functionalities as discussed herein as well as a set ofapplications 820 (e.g., which may be implemented as machine readable orcomputer-executable instructions). The operating system 818 may includeone of a plurality of general purpose or mobile platforms, such as theAndroid™, iOS®, or Windows® systems, developed by Google Inc., AppleInc., and Microsoft Corporation, respectively. Alternatively, theoperating system 818 may be a custom operating system designed for theon-board electronic device 810. The processor 812 may interface with thememory 815 to execute the operating system 818 and the set ofapplications 820, and to access data stored in the memory 815. Thememory 815 may include one or more forms of tangible, non-transitoryvolatile and/or non-volatile, fixed and/or removable memory, such asread-only memory (ROM), electronic programmable read-only memory(EPROM), random access memory (RAM), erasable electronic programmableread-only memory (EEPROM), and/or other hard drives, flash memory,MicroSD cards, and others.

Turning to the applications 820 stored at the local electronic device810, in an embodiment, one of the set of applications 820 may be amonitoring application 821 for monitoring an environment in which thevehicle that is transporting the local electronic device 810 (e.g., thesubject vehicle) is operating. Another application may be an anomalousvehicle behavior application 822 configured to apply an anomalousvehicle behavior model (e.g., the model 478) to determine if a remotevehicle is exhibiting anomalous behavior and provide mitigation actionto the vehicle operator if the remote vehicle is exhibiting anomalousbehavior. Another one of the set of applications 820 may be a navigationapplication 823 configured to generate navigation directions. Stillanother one of the set of applications 820 may be a log generationapplication 824 configured to generate and record logs including variousvehicle operation data. Each of the set of applications 820 may accesseach other in order to effectively perform its function. For example,the anomalous vehicle behavior application 822 may interface with thenavigation application 823 to generate alternate navigation directionsto mitigate the effect of detecting that a remote vehicle is exhibitinganomalous behavior. In another example, the anomalous vehicle behaviorapplication 822 may interface with the log generation application 823 tolog a record of a determined anomalous behavior of a remote vehicle. Itshould be appreciated that one or more other applications 824, 825 areenvisioned. Generally speaking, the applications 820 may perform one ormore techniques related to detecting and mitigating anomalous remotevehicle behavior, e.g., in real-time. For example, one or more of theapplications 821-825 may perform at least a portion of (and in somecases, the entirety of) any of the methods described herein. In someembodiments, one or more applications 821-825 may operate in conjunctionwith one or more applications 761-765 at the remote server 460 toperform at least a portion of (and in some cases, the entirety of) anyof the methods described herein.

Additionally, the various applications 820 may be executed on the samecomputer processor 812 or on different computer processors. Further,while the various applications 821-825 are depicted as separateapplications, two or more of the applications 821-825 may be integratedas an integral application, if desired. In some embodiments, at leastone of the applications 821-825 may be implemented in conjunction withanother application (not shown) that is stored and executed at thedevice 810, e.g., a user interface application, a driver performanceevaluation application, etc.

According to some embodiments, the memory 815 may also include a set ofhistorical vehicle behavior data 830 obtained by a plurality of sensorswhile a plurality of drivers operated a plurality of vehicles overvarious routes during various contextual conditions, e.g., thehistorical data 475. Additionally or alternatively, the memory 815 maystore anomalous vehicle behavior models 478, anomalous vehicle behaviorcharacteristics 476, identities of anomalous vehicle behaviors in therespective mappings to sets of vehicle behavior characteristics, and/orother data related to detecting and mitigating anomalous behavior ofremote vehicles (not shown). At least some of the data stored in thememory 815 may be determined or generated based upon at least a part ofthe historical vehicle behavior data 830, in an embodiment. Inembodiments, the memory 815 may additionally store other types of datarelated to vehicle operations, vehicle environments, contextualconditions, driver performances, etc. Generally, at least some of thedata points of the historical vehicle behavior data 830 (and optionally,other data stored in the memory 815) may be time-stamped and may includean indication of a respective geo-location in which the data point wascollected. That is, at least a portion of the data stored in the memory815 may include time-series data.

In some implementations, the anomalous vehicle behavior application 821and/or other applications 822-825 may interface with the set ofhistorical vehicle behavior data 830 and other data stored on the memory815 in order to determine if a remote vehicle is exhibiting anomalousbehavior. In some embodiments, the anomalous vehicle behaviorapplication 821 and/or other applications 822-825 may interface with orotherwise be communicatively connected to other data storage mechanisms(e.g., one or more hard disk drives, optical storage drives, solid statestorage devices, etc.) that reside within the vehicle via which thelocal electronic device 810 is being transported, and/or that areaccessible to the remote server 460.

As such, the on-board electronic device 810 may further include acommunication module 835 configured to communicate data, e.g., directlyto another device, or via one or more networks 840. For example, thenetwork(s) 840 may include the network(s) 450 and/or the network(s) 732.According to some embodiments, the communication module 835 may includeone or more transceivers which may be configured to receive and transmitdata via one or more external ports 842. The one or more transceiversmay operate in accordance with any suitable communication protocol, suchas those used for wireless telephony (e.g., GSM, CDMA, LTE, etc.), Wi-Fior other 802.11 standards, WiMAX, etc. Further, the communication module835 may include a short-range network component (e.g., an RFID reader, aBluetooth transceiver, an infrared transceiver, etc.) that is configuredfor short-range network communications (not shown). For example, thecommunication module 835 may receive, via the short-range networkcomponent and/or one or more of the external ports 842, sensor data froma set of sensors, which may be on-board sensors and/or off-board sensorswith respect to the subject vehicle by which the on-board electronicdevice 810 is being transported. For instance, the communication module825 may receive sensor data generated by on-board sensors via ashort-range network component or port, and may receive sensor datagenerated by off-board sensors from a remote server via the network 840and/or directly from proximate vehicles.

The local electronic device 810 may further include a set of sensors845. The set of sensors 845 may include, for example, a GPS unit, anaccelerometer, a gyroscope, a magnetometer, a proximity sensor, a lightsensor, a Hall Effect sensor, an optical sensor, an audio sensor, etc.The processor 812 and the set of applications 820 may interface with theset of sensors 845 to retrieve and process corresponding sensor datagenerated by the sensors 845 included in the local electronic device810, which may be utilized to determine and mitigate anomalous vehiclebehavior in real-time.

The local electronic device 810 may include a user interface 848 that isconfigured to present information to a user and/or receive inputs fromthe user. As shown in FIG. 8 , the user interface 848 may include adisplay screen 850 and I/O components 852 (e.g., ports, capacitive orresistive touch sensitive input panels, keys, buttons, lights, LEDs,speakers, microphones, etc.). According to some embodiments, the usermay access the electronic device 810 via the user interface 848 toreview information and/or perform other functions or techniques relatedto detecting and mitigating anomalous behavior of a remote vehicle. Theset of applications 820, external ports 842, communication module 835,memory 815, set of sensors 845, processor 812, and user interface 848may interface with each other via an input/output (I/O) circuit 855.

In general, a computer program product in accordance with an embodimentmay include one or more computer-usable, tangible, non-transitorystorage media (e.g., standard random access memory (RAM), an opticaldisc, a universal serial bus (USB) drive, or the like) havingcomputer-readable or computer-executable program code or instructionsembodied or stored therein, wherein the computer-readable/executableprogram code/instructions may be adapted to be executed by the processor812 (e.g., working in connection with the operating system 818) tofacilitate any one or more of the novel techniques described herein. Inthis regard, the program code may be implemented in any desiredlanguage, and may be implemented as machine code, assembly code, bytecode, interpretable source code or the like (e.g., via C, C++, Java,Actionscript, Objective-C, Javascript, CSS, XML, Python, or any desiredprogramming language).

Although the text herein sets forth a detailed description of numerousdifferent embodiments, it should be understood that the legal scope ofthe invention may be defined by the words of the claims set forth at theend of this patent. The detailed description is to be construed asexemplary only and does not describe every possible embodiment, asdescribing every possible embodiment would be impractical, if notimpossible. One could implement numerous alternate embodiments, usingeither current technology developed after the filing date of thispatent, which would still fall within the scope of the claims.

It should also be understood that, unless a term is expressly defined inthis patent using the sentence “As used herein, the term ‘______’ ishereby defined to mean . . . ” or a similar sentence, there is no intentto limit the meaning of that term, either expressly or by implication,beyond its plain or ordinary meaning, and such term should not beinterpreted to be limited in scope based upon any statement made in anysection of this patent (other than the language of the claims). To theextent that any term recited in the claims at the end of this disclosureis referred to in this disclosure in a manner consistent with a singlemeaning, that is done for sake of clarity only so as to not confuse thereader, and it is not intended that such claim term be limited, byimplication or otherwise, to that single meaning. Additionally, thepatent claims at the end of this patent application are not intended tobe construed under 35 U.S.C. § 112(f) unless traditionalmeans-plus-function language is expressly recited, such as “means for”or “step for” language being explicitly recited in the claim(s). Thesystems and methods described herein are directed to an improvement tocomputer functionality, and improve the functioning of conventionalcomputers.

Throughout this specification, plural instances may implementcomponents, operations, or structures described as a single instance.Although individual operations of one or more methods are illustratedand described as separate operations, one or more of the individualoperations may be performed concurrently, and nothing requires that theoperations be performed in the order illustrated. Structures andfunctionality presented as separate components in example configurationsmay be implemented as a combined structure or component. Similarly,structures and functionality presented as a single component may beimplemented as separate components. These and other variations,modifications, additions, and improvements fall within the scope of thesubject matter herein.

Additionally, certain embodiments are described herein as includinglogic or a number of routines, subroutines, applications, orinstructions. These may constitute either software (e.g., code embodiedon a non-transitory, machine-readable medium) or hardware. In hardware,the routines, etc., are tangible units capable of performing certainoperations and may be configured or arranged in a certain manner. Inexample embodiments, one or more computer systems (e.g., a standalone,client or server computer system) or one or more hardware modules of acomputer system (e.g., a processor or a group of processors) may beconfigured by software (e.g., an application or application portion) asa hardware module that operates to perform certain operations asdescribed herein.

In various embodiments, a hardware module may be implementedmechanically or electronically. For example, a hardware module maycomprise dedicated circuitry or logic that may be permanently configured(e.g., hardwired, as a special-purpose processor, such as a fieldprogrammable gate array (FPGA) or an application-specific integratedcircuit (ASIC)) to perform certain operations. A hardware module mayalso comprise programmable logic or circuitry (e.g., as encompassedwithin a general-purpose processor or other programmable processor) thatmay be temporarily configured by software (e.g., programmed) to performcertain operations at any one instance in time. For example, where themodules comprise a general-purpose processor configured using software,the general-purpose processor may be configured as respective differentmodules at different times. Software may accordingly configure aprocessor, for example, to constitute a particular module at oneinstance of time and to constitute a different module at a differentinstance of time. It will be appreciated that the decision to implementa hardware module mechanically, in dedicated and permanently configuredcircuitry, or in temporarily configured circuitry (e.g., configured bysoftware) may be driven by cost and time considerations.

Accordingly, the term “hardware module” should be understood toencompass a tangible entity, be that an entity that is physicallyconstructed, permanently configured (e.g., hardwired), or temporarilyconfigured (e.g., programmed) to operate in a certain manner or toperform certain operations described herein. Considering embodiments inwhich hardware modules are temporarily configured (e.g., programmed),each of the hardware modules need not be configured or instantiated atany one instance in time. For example, where the hardware modulescomprise a general-purpose processor configured using software, thegeneral-purpose processor may be configured as respective differenthardware modules at different times. Software may accordingly configurea processor, for example, to constitute a particular hardware module atone instance of time and to constitute a different hardware module at adifferent instance of time.

Hardware modules may provide information to, and receive informationfrom, other hardware modules. Accordingly, the described hardwaremodules may be regarded as being communicatively coupled. Where multipleof such hardware modules exist contemporaneously, communications may beachieved through signal transmission (e.g., over appropriate circuitsand busses) that connect the hardware modules. In embodiments in whichmultiple hardware modules are configured or instantiated at differenttimes, communications between such hardware modules may be achieved, forexample, through the storage and retrieval of information in memorystructures to which the multiple hardware modules have access. Forexample, one hardware module may perform an operation and store theoutput of that operation in a memory device to which it may becommunicatively coupled. A further hardware module may then, at a latertime, access the memory device to retrieve and process the storedoutput. Hardware modules may also initiate communications with input oroutput devices, and may operate on a resource (e.g., a collection ofinformation).

The various operations of example methods described herein may beperformed, at least partially, by one or more processors that aretemporarily configured (e.g., by software) or permanently configured toperform the relevant operations. Whether temporarily or permanentlyconfigured, such processors may constitute processor-implemented modulesthat operate to perform one or more operations or functions. The modulesreferred to herein may, in some example embodiments, compriseprocessor-implemented modules.

Similarly, the methods or routines described herein may be at leastpartially processor-implemented. For example, at least some of theoperations of a method may be performed by one or more processors orprocessor-implemented hardware modules. The performance of certain ofthe operations may be distributed among the one or more processors, notonly residing within a single machine, but deployed across a number ofmachines. In some example embodiments, the processor or processors maybe located in a single location (e.g., within a home environment, anoffice environment, or as a server farm), while in other embodiments theprocessors may be distributed across a number of locations.

The performance of certain of the operations may be distributed amongthe one or more processors, not only residing within a single machine,but deployed across a number of machines. In some example embodiments,the one or more processors or processor-implemented modules may belocated in a single geographic location (e.g., within a homeenvironment, an office environment, or a server farm). In other exampleembodiments, the one or more processors or processor-implemented modulesmay be distributed across a number of geographic locations.

Unless specifically stated otherwise, discussions herein using wordssuch as “processing,” “computing,” “calculating,” “determining,”“presenting,” “displaying,” or the like may refer to actions orprocesses of a machine (e.g., a computer) that manipulates or transformsdata represented as physical (e.g., electronic, magnetic, or optical)quantities within one or more memories (e.g., volatile memory,non-volatile memory, or a combination thereof), registers, or othermachine components that receive, store, transmit, or displayinformation.

As used herein any reference to “one embodiment” or “an embodiment”means that a particular element, feature, structure, or characteristicdescribed in connection with the embodiment may be included in at leastone embodiment. The appearances of the phrase “in one embodiment” invarious places in the specification are not necessarily all referring tothe same embodiment.

As used herein, the terms “comprises,” “comprising,” “may include,”“including,” “has,” “having” or any other variation thereof, areintended to cover a non-exclusive inclusion. For example, a process,method, article, or apparatus that comprises a list of elements is notnecessarily limited to only those elements but may include otherelements not expressly listed or inherent to such process, method,article, or apparatus. Further, unless expressly stated to the contrary,“or” refers to an inclusive or and not to an exclusive or. For example,a condition A or B is satisfied by any one of the following: A is true(or present) and B is false (or not present), A is false (or notpresent) and B is true (or present), and both A and B are true (orpresent).

In addition, use of the “a” or “an” are employed to describe elementsand components of the embodiments herein. This is done merely forconvenience and to give a general sense of the description. Thisdescription, and the claims that follow, should be read to include oneor at least one and the singular also may include the plural unless itis obvious that it is meant otherwise.

This detailed description is to be construed as exemplary only and doesnot describe every possible embodiment, as describing every possibleembodiment would be impractical, if not impossible. One could implementnumerous alternate embodiments, using either current technology ortechnology developed after the filing date of this application. Uponreading this disclosure, those of skill in the art will appreciate stilladditional alternative structural and functional designs for system anda method for assigning mobile device data to a vehicle through thedisclosed principles herein. Thus, while particular embodiments andapplications have been illustrated and described, it is to be understoodthat the disclosed embodiments are not limited to the preciseconstruction and components disclosed herein. Various modifications,changes and variations, which will be apparent to those skilled in theart, may be made in the arrangement, operation and details of the methodand apparatus disclosed herein without departing from the spirit andscope defined in the appended claims.

The particular features, structures, or characteristics of any specificembodiment may be combined in any suitable manner and in any suitablecombination with one or more other embodiments, including the use ofselected features without corresponding use of other features. Inaddition, many modifications may be made to adapt a particularapplication, situation or material to the essential scope and spirit ofthe present invention. It is to be understood that other variations andmodifications of the embodiments of the present invention described andillustrated herein are possible in light of the teachings herein and areto be considered part of the spirit and scope of the present invention.

While the preferred embodiments of the invention have been described, itshould be understood that the invention is not so limited andmodifications may be made without departing from the invention. Thescope of the invention is defined by the appended claims, and alldevices that come within the meaning of the claims, either literally orby equivalence, are intended to be embraced therein. It is thereforeintended that the foregoing detailed description be regarded asillustrative rather than limiting, and that it be understood that it isthe following claims, including all equivalents, that are intended todefine the spirit and scope of this invention.

What is claimed:
 1. A method, comprising: determining, using one or moreprocessors, and based upon sensor data from one or more sensorsassociated with the first vehicle, that a second vehicle is exhibitingan anomalous behavior; and communicating an indication of the anomalousbehavior of the second vehicle to an electronic device associated with athird vehicle for presentation via a user interface associated with thethird vehicle, the third vehicle being distinct from the second vehicle.2. The method of claim 1, further comprising: monitoring a vehicleenvironment in which the first vehicle is operating using data collectedby at least one of: a first set of sensors disposed at the firstvehicle; a second set of sensors disposed in the vehicle environmentexternal to the first vehicle, the second set of sensors fixedlyattached to one or more other vehicles operating in the vehicleenvironment; or a third set of sensors disposed in the vehicleenvironment external to the first vehicle, the third set of sensorsfixedly attached to one or more fixtures or infrastructure componentsdisposed in the vehicle environment.
 3. The method of claim 2, whereinmonitoring the vehicle environment comprises monitoring a set of currentbehaviors of one or more other vehicles within a threshold distance ofthe first vehicle, the one or more other vehicles including the secondvehicle.
 4. The method of claim 3, wherein monitoring the vehicleenvironment further comprises monitoring a set of current contextualconditions of the vehicle environment.
 5. The method of claim 1, whereindetermining that the second vehicle is exhibiting the anomalous behaviorincludes comparing a set of characteristics indicative of one or morebehaviors of the second vehicle with a set of anomalous vehicle behaviorcharacteristics by applying a model to the set of characteristicsindicative of the one or more behaviors of the second vehicle, the modelgenerated based upon a statistical analysis or a learning methodperformed on a set of historical vehicle behavior data, the set ofhistorical vehicle behavior data based upon data obtained by a pluralityof sensors while a plurality of drivers operated a plurality ofvehicles.
 6. The method of claim 5, wherein determining the secondvehicle is exhibiting the anomalous behavior comprises determining thesecond vehicle is exhibiting the anomalous behavior based upon an outputgenerated from the application of the model to the set ofcharacteristics indicative of the one or more behaviors of the secondvehicle.
 7. The method of claim 6, wherein: the output generated fromthe application of the model to the set of characteristics indicative ofthe one or more behaviors of the second vehicle includes an indicationof one or more mitigation actions corresponding to the anomalousbehavior; and mitigating the effect of the anomalous behavior furtherincludes suggesting or performing the one or more mitigation actions. 8.The method of claim 1, further comprising mitigating the effect of theanomalous behavior of the second vehicle by at least one of: providing afirst instruction to automatically modify an operating behavior of thefirst vehicle, the first instruction based upon the detected, anomalousbehavior of the second vehicle; or providing a second instruction toautomatically modify an operating behavior of the third vehicleoperating within the vehicle environment, the second instruction basedupon the detected, anomalous behavior of the second vehicle.
 9. Themethod of claim 1, further comprising mitigating an effect of theanomalous behavior of the second vehicle by at least one of: providingan indication of the detected, anomalous behavior of the second vehiclefor presentation via a user interface disposed in the first vehicle; orproviding an indication of a suggested modification to an operatingbehavior of the first vehicle for presentation via the user interfacedisposed in the first vehicle.
 10. The method of claim 1, furthercomprising mitigating an effect of the anomalous behavior of the secondvehicle by automatically notifying a public safety authority of thedetected, anomalous behavior of the second vehicle.
 11. The method ofclaim 1, further comprising determining the set of anomalous vehiclebehavior characteristics based upon a set of historical vehicle behaviordata, the set of historical vehicle behavior data including dataindicative of historical contextual conditions.
 12. A system,comprising: one or more processors configured to receive sensor datafrom one or more sensors associated with a first vehicle; one or moretangible, non-transitory computer-readable media coupled to the one ormore processors; and computer-executable instructions stored on the oneor more tangible, non-transitory computer-readable media that, whenexecuted by the one or more processors, cause the system to: determine,based upon the sensor data, that a second vehicle is exhibiting ananomalous behavior; and communicating an indication of the anomalousbehavior of the second vehicle to an electronic device associated with athird vehicle for presentation via a user interface associated with thethird vehicle, the third vehicle being distinct from the second vehicle.13. The system of claim 12, wherein at least a portion of the one ormore processors associated with the first vehicle is disposed in atleast one of: (i) an electronic device that is fixedly attached to thefirst vehicle, or (ii) a portable device associated with the firstdriver and disposed in the first vehicle.
 14. The system of claim 13,wherein: the computer-executable instructions, when executed by the oneor more processors, further cause the system to determine that thesecond vehicle is exhibiting the anomalous behavior based on comparing aset of characteristics indicative of the one or more behaviors of thesecond vehicle with a set of anomalous vehicle behavior characteristics;and wherein at least another portion of the one or more processorsassociated with the first vehicle is disposed at one or more remoteservers that are associated with the first vehicle and that arecommunicatively connected, via one or more communication interfaces, tothe at least one of the electronic device that is fixedly attached tothe first vehicle, or the portable device associated with the firstdriver and disposed in the first vehicle; and at least a portion of theset of anomalous vehicle behavior characteristics is accessible to theone or more remote servers.
 15. The system of claim 12, wherein thecomputer-executable instructions, when executed by the one or moreprocessors, further cause the system to determine that the secondvehicle is exhibiting the anomalous behavior based on comparing a set ofcharacteristics indicative of the one or more behaviors of the secondvehicle with a set of anomalous vehicle behavior characteristics; andwherein at least a subset of the set of anomalous vehicle behaviorcharacteristics is generated from a set of historical vehicle behaviordata by using at least one of a statistical analysis or a learningmethod, the set of historical vehicle behavior data corresponding todata obtained by a plurality of sensors while a plurality of driversoperated a plurality of vehicles.
 16. The system of claim 12, whereinthe set of sensors associated with the first vehicle operated by thefirst driver includes at least one of: a first set of sensors disposedat the first vehicle; or a second set of sensors disposed at one or moreother vehicles operating in the vehicle environment; or a third set ofsensors disposed on one or more stationary fixtures disposed in thevehicle environment.
 17. The system of claim 12, wherein at least one ofthe first vehicle or the third vehicle is an autonomous vehicle.
 18. Thesystem of claim 12, wherein the first vehicle and the third vehicle arecommunicatively connected via one or more communication interfaces. 19.One or more non-transitory computer-readable storage media storingcomputer-readable instructions to be executed on one or more processorsof a system, the computer-readable instructions, when executed by theone or more processors, causing the system to: determine, based uponsensor data from one or more sensors associated with a first vehicle,that a second vehicle is exhibiting an anomalous behavior; andcommunicating an indication of the anomalous behavior of the secondvehicle to an electronic device associated with a third vehicle forpresentation via a user interface associated with the third vehicle, thethird vehicle being distinct from the second vehicle.
 20. The one ormore non-transitory computer-readable storage media of claim 19, whereinthe computer-readable instructions, when executed by the one or moreprocessors, further cause the system to at least one of: (a) provide afirst instruction to automatically modify an operating behavior of thefirst vehicle, the first instruction based upon the detected, anomalousbehavior of the second vehicle; (b) provide a second instruction toautomatically modify an operating behavior of the third vehicleoperating within the vehicle environment, the second instruction basedupon the detected, anomalous behavior of the second vehicle; (c) providean indication of the detected, anomalous behavior of the second vehiclefor presentation via at least one of a user interface disposed in thefirst vehicle or a user interface disposed in the third vehicleoperating within the vehicle environment; or (d) provide an indicationof a suggested modification to an operating behavior of the firstvehicle for presentation via the user interface disposed in the firstvehicle.